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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server (http://www.etsi.org/ipr ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ECMA on behalf of its members and those of the European 
Telecommunications Standards Institute (ETSI). 



Brief history 



The present document is one of a series of ECMA Standards defining the interworking of services and signalling 
protocols deployed in Corporate telecommunication Networks (CNs). The series uses telecommunication concepts as 
developed by ITU-T and conforms to the framework of International Standards on Open Systems Interconnection as 
defined by ISO/IEC. It has been produced under ETSI work item DTS/ECMA-00195. 

The present document defines the signalling protocol interworking for call transfer supplementary services between a 
Private Integrated Services Network (PISN) and a packet-based private telecommunications network based on the 
Internet Protocol (IP). It is further assumed that the protocol for the PISN part is that defined for the Q reference point 
(QSIG) and that the protocols for the IP-based network are based on ITU-T Recommendation H.323. 

The present document is based upon the practical experience of ECMA member companies and the results of their 
active and continuous participation in the work of ISO/IEC JTCl, ITU-T, ETSI and other international and national 
standardization bodies. It represents a pragmatic and widely based consensus. 

The present document is in complete alignment with International Standard ISO/IEC 21410: 2001(E) to be published by 
ISO/IEC in 2001. 

Adopted as 2nd Edition of Standard ECMA-308 by the General Assembly of June 2001. 
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1 Scope 



The present document specifies signalling interworking between "QSIG" and "H.323" in support of the call transfer 
supplementary services within a Corporate telecommunication Network (CN). 

"QSIG" is a signalling protocol that operates at the Q reference point between Private Integrated Services eXchanges 
(PINX) within a Private Integrated Services Network (PISN). The Q reference point is defined in ECMA-133. A PISN 
provides circuit-switched basic services and supplementary services to its users. QSIG is specified in other standards, in 
particular ECMA-143 (call control in support of basic services), ECMA-165 (generic functional protocol for the support 
of supplementary services) and a number of standards specifying individual supplementary services. ECMA-178 
specifies the QSIG protocol in support of call transfer by consultation and ECMA-300 specifies the QSIG protocol in 
support of single step call transfer. 

"H.323" is a set of signalling protocols for the support of voice or multimedia communication within a packet network, 
in particular a packet network that uses the Internet Protocol (IP) as its network layer protocol (IP network). H.323 
signalling protocols operate between endpoints in an IP network, either indirectly via one or more gatekeepers, or 
directly. An endpoint can be a terminal or a gateway to another network. H.323 is an "umbrella" recommendation 
referring to various ITU-T Recommendations, in particular Recommendations H.225.0 and H.245 (basic 
communication capabilities) and ITU-T Recommendation H.450. 1 (generic functional protocol for the support of 
supplementary services). ITU-T Recommendation H.450.2 specifies the H.323 protocol in support of call transfer. 

NOTE: H.450.2 applies only to the 1998 version of H.323 (also known as H.323 version 2) and to later versions. 

Call transfer by consultation, as supported by ECMA-178, is a supplementary service that enables a user (user A) to 
transform two of that user's calls (at least one of which must be answered) into a new call between the two other users in 
the two calls (users B and C). 

Single step call transfer, as supported by ECMA-300, is a supplementary service that enables a user (user A) to 
transform an existing call between user A and user B into a new call between user B and user C without user A needing 
to establish a call with user C prior to transfer. 

Call transfer, as supported by H.450.2, is a supplementary service that enables the served user (user A) to transform an 
existing call with a second user (user B) into a new call between user B and a third user (user C) selected by user A. 
User A may or may not have a call established with user C prior to call transfer. If a call is already established between 
user A and user C, this is known as transfer by consultation and is equivalent to call transfer as supported by 
ECMA-178. If a call is not already established between user A and user C, this is known as single step call transfer and 
is equivalent to call transfer as supported by ECMA-300. 

Interworking between QSIG and H.323 permits a call originating at a user of a PISN to terminate at a user of an IP 
network, or a call originating at a user of an IP network to terminate at a user of a PISN. The present document provides 
the following additional capabilities: 

• a PISN user with two calls established, at least one of which being to or from a user in an IP network, to be able 
to transform those two calls into a new call between the other two users involved; 

• a PISN user with a call established to or from a user in an IP network to be able to transform that call into a new 
call between the IP network user and a third user selected by the PISN user, that third user being either in the IP 
network or in the PISN; 

• a PISN user with a call established to a second PISN user to be able to transfer that call into a new call between 
the second user and a third user selected by the first user, that third user being in an IP network; 

• an IP network user with two calls established, at least one of which being to or from a user in a PISN, to be able 
to transform those two calls into a new call between the other two users involved; 

• an IP network user with a call established to or from a user in a PISN to be able to transform that call into a new 
call between the PISN user and a third user selected by the IP network user, that third user being either in the IP 
network or in the PISN; and 

• an IP network user with a call established to a second user in the IP network to be able to transfer that call into a 
new call between the second user and a third user selected by the first user, that third user being in a PISN. 
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The present document is applicable to any interworking unit that can act as a gateway between a PISN employing QSIG 
and an IP network employing H.323. 



2 Conformance 

In order to conform to the present document, a gateway shall satisfy the requirements identified in the Implementation 
Conformance Statement (ICS) proforma in annex A. 



3 Normative references 

The following standards contain provisions which, through reference in this text, constitute provisions of this Standard. 
All standards are subject to revision, and parties to agreements based on this Standard are encouraged to investigate the 
possibility of applying the most recent editions of the standards indicated below. 

In the case of references to ECMA Standards that are aligned with ISO/IEC International Standards, the number of the 
appropriate ISO/IEC International Standard is given in brackets after the ECMA reference. 

ECMA- 133: "Private Integrated Services Network (PISN) - Reference Configurations for PISN Exchanges (PINX), 
2nd edition" (International Standard ISO/IEC 11579-1). 

ECMA- 143: "F*rivate Integrated Services Network (PISN) - Circuit Mode Bearer Services - Inter-Exchange Signalling 
Procedures and Protocol (QSIG-BC), 3rd edition" (International Standard ISO/IEC 11572). 

ECMA-165: "F*rivate Integrated Services Network (PISN) - Generic Functional Protocol for the Support of 
Supplementary Services - Inter-Exchange Signalling Procedures and Protocol (QSIG-GF), 4th edition" (International 
Standard ISO/IEC 11582). 

ECMA- 178: "Private Integrated Services Network (PISN) - Inter-Exchange Signalling Protocol - Call Transfer 
Supplementary Service (QSIG-CT), 2nd edition" (International Standard ISO/IEC 13869). 

ECMA-300: "Private Integrated Services Network (PISN) - Inter-Exchange Signalling Protocol - Single Step Call 
Transfer Supplementary Service (QSIG-SSCT)" (International Standard ISO/IEC 19460). 

ECMA-307: "Corporate Telecommunication Networks - Signalling Interworking between QSIG and H.323 - Generic 
Functional Protocol for the Support of Supplementary Services" (International Standard ISO/IEC 21409). 

ITU-T Recommendation H.225.0 (2000): "Call signalling protocols and media stream packetization for packet-based 
multimedia communication systems". 

ITU-T Recommendation H.245 (2000): "Control protocol for multimedia communication". 

ITU-T Recommendation H.323 (2000): "Packet-based multimedia communications systems". 

ITU-T Recommendation H.450.1 (1998): "Generic functional protocol for the support of supplementary services in 

H.323". 

ITU-T Recommendation H.450.2 (1998): "Call transfer supplementary service for H.323". 
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4 Definitions 

For the purposes of the present document, the following terms and definitions apply. 

4.1 External definitions 

The present document uses the following terms defined in other documents: 

• Call (ECMA-307) 

• Corporate telecommunication Network (CN) (ECMA-307) 

• Endpoint (ITU-T Recommendation H.323) 

• IP network (ECMA-307) 

• Gatekeeper (ITU-T Recommendation H.323) 

• Private Integrated Services Network (PISN) (ECMA-307) 

• Private Integrated services Network exchange (PINX) (ECMA-133) 

Additionally the definitions in ECMA-178, ECMA-300 and ITU-T Recommendation H.450.2 apply as appropriate. 

4.2 Other definitions 

4.2.1 Entity A 

In call transfer by consultation, the signalling entity at the PINX or H.323 endpoint serving the transferring user 
(user A). 

4.2.2 Entity A* 

In single step call transfer, the signalling entity at the PINX or H.323 endpoint serving the transferring user (user A). 

4.2.3 Entity B 

In call transfer by consultation, the signalling entity in the PISN or IP network associated with the call between the 
transferring user (user A) and the transferred user (user B). 

4.2.4 Entity B* 

In single step call transfer, the signalling entity in the PISN or IP network associated with the call between the 
transferring user (user A) and the transferred user (user B). 

4.2.5 Entity B' 

Signalling entity at the PINX or the H.323 endpoint serving the transferred user (user B). 

4.2.6 Entity C 

In call transfer by consultation, the signalling entity in the PISN or IP network associated with the call between the 
transferring user (user A) and the transferred-to-user (user C). 
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4.2.7 Entity C 



In single step call transfer, the signalling entity in the PISN or IP network associated with the call between the 
transferred user (user B) and the transferred-to-user (user C). 

4.2.8 Entity C 

Signalling entity at the PINX or H.323 endpoint serving the transferred-to-user (user C). 

4.2.9 Gateway 

A gateway as defined in H.323 specifically for the purpose of interworking with a network employing QSIG. 

4.2.10 LegAB 

In call transfer by consultation, the call segment that lies between entity A and entity B. 

4.2.11 LegAB* 

In single step call transfer, the call segment that lies between entity A* and entity B*. 

4.2.12 Leg AC 

In call transfer by consultation, the call segment that lies between entity A and entity C. 

4.2.13 LegBC 

In call transfer by consultation, the call segment that lies between entity B and entity C. 

4.2.14 LegBC* 

In single step call transfer, the call segment that lies between entity B* and entity C*. 

4.2.15 Leg B 

In call transfer by consultation, the call segment that lies between the entity B and entity B'. 

4.2.16 Leg B* 

In single step call transfer, the call segment that lies between entity B* and entity B'. 

4.2.17 Lege 

In call transfer by consultation, the call segment that lies between entity C and entity C. 

4.2.18 Scenario AB1 

Interworking arrangement in which entity A (PINX A) is in the PISN and entity B is in the IP network. 

4.2.19 Scenario AB*1 

Interworking arrangement in which entity A* (PINX A) is in the PISN and entity B* is in the IP network. 
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4.2.20 Scenario AB2 

Interworking arrangement in which entity A (endpoint A) is in the IP network and entity B is in the PISN. 

4.2.21 Scenario AB*2 

Interworking arrangement in which entity A* (endpoint A) is in the IP network and entity B* is in the PISN. 

4.2.22 Scenario AC1 

Interworking arrangement in which entity A (PINX A) is in the PISN and entity C is in the IP network. 

4.2.23 Scenario AC2 

Interworking arrangement in which entity A (endpoint A) is in the IP network and entity C is in the PISN. 

4.2.24 Scenario BC1 

Interworking arrangement in which entity B (PINX B) is in the PISN and entity C is in the IP network. 

4.2.25 Scenario BC*1 

Interworking arrangement in which entity B* (PINX B) is in the PISN and entity C* is in the IP network. 

4.2.26 Scenario BC2 

Interworking arrangement in which entity B is in the IP network and entity C is in the PISN. 

4.2.27 Scenario BC*2 

Interworking arrangement in which entity B* is in the IP network and entity C* is in the PISN. 

4.2.28 Scenario B1 

Interworking arrangement in which entity B (PINX B) is in the PISN and entity B' is in the IP network. 

4.2.29 Scenario B*1 

Interworking arrangement in which entity B* (PINX B) is in the PISN and entity B' is in the IP network. 

4.2.30 Scenario B2 

Interworking arrangement in which entity B (diverting endpoint or its gatekeeper) is in the IP network and entity B' is in 
the PISN. 

4.2.31 Scenario B*2 

Interworking arrangement in which entity B* (diverting endpoint or its gatekeeper) is in the IP network and entity B' is 
in the PISN. 

4.2.32 Scenario CI 

Interworking arrangement in which entity C (PINX C) is in the PISN and entity C is in the IP network. 
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4.2.33 Scenario C2 

Interworking arrangement in which entity C (endpoint C) is in the IP network and entity C is in the PISN. 



Acronyms 



APDU Application Protocol Data Unit 

CN Corporate telecommunication Network 

ICS Implementation Conformance Statement 

IP Internet Protocol 

PINX Private Integrated services Network eXchange 

PISN Private Integrated Services Network 

SS-CT Supplementary Service Call Transfer 

SS-SSCT Supplementary Service Single Step Call Transfer 



6 Service architecture 

6.1 Service architecture for invocation and operation 
6.1 .1 QSIG service arciiitecture 

QSIG supports two different call transfer services: 

• transfer by consultation (ECMA-178); and 

• single step call transfer (ECMA-300). 

6.1 .1 .1 ECMA-1 78 service architecture - transfer by consultation 

ECMA-178 supports a call transfer service that starts from a situation where user A has two calls (typically one of 
which is on hold). Transfer from this situation can be performed in two ways: by join (at the PINX serving user A) or 
by rerouteing. 

A single model can be derived to accommodate both scenarios. The model involves five signalling entities as follows: 

• entity A - acts on behalf of user A and co-ordinates the transfer; 

• entity B - initiates the re-routed connection fi^om the first transferred user (user B) to the other transferred user 
(user C); 

• entity B' - acts on behalf of user B; 

• entity C - terminates the re-routed connection from user B to user C and completes the join; and 

• entity C - acts on behalf of user C. 
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This can be represented diagrammatically as shown in figure 1 . 



Leg AB 



Entity A 




Entity B 



LegB 



Entity B' 



LegBC 



Leg AC 



Entity C 



Lege 



Entity C 



Figure 1 : Generalized caii transfer model for QSIG transfer by consultation 

From this it can be seen that there are five segments or "legs" to the call: 

• leg AB between entity A and entity B; 

• leg AC between entity A and entity C; 

• leg BC between entity B and entity C; 

• leg B between entity B and entity B'; and 

• leg C between entity C and entity C. 

The protocol defined in ECMA-178 supports each of these five legs. 

For both transfer by join and transfer by rerouteing, entities A, B' and C are located at the PINX serving user A, user B 
and user C respectively. 

For call transfer by join, entities B and C are collocated with entity A in the PINX serving user A. This means that legs 
AB, AC and BC are all internal to that PINX, and therefore the QSIG protocols for these legs do not apply. Only the 
QSIG protocols for legs B and C apply. This is shown in figure 2. 



PINXB 



PINX A 




Entity A 



Entity B 



Entity C 




PINXC 



Figure 2: Call transfer by join model for QSIG 
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For call transfer by rerouteing, entity B is collocated with entity B' in the PINX serving user B, and entity C is 
collocated with entity C in the PINX serving user C. This means that legs B and C are internal to the respective PINXs, 
and therefore the QSIG protocols for these legs do not apply. Only the QSIG protocols for legs AB, AC and BC apply. 
This is shown in figure 3. 



PINXB 



Leg AB 



PINX A 




Leg AC 



Entity B 


Entity B' 




Leg BC 


Entity C 


Entity C 



PINXC 



Figure 3: Call transfer by rerouteing model for QSIG 

In both cases (transfer by join and transfer by rerouteing), where a user is in another network, the role of entity A, entity 
B' or entity C is performed by the other network, the gateway PINX or the two in combination. However, fi"om the 
QSIG point of view the role is performed by the gateway PINX. 



6.1.1.2 



ECMA-300 service architecture - single step call transfer 



ECMA-300 supports a call transfer service that starts from a situation where user A has an active call with user B and 
the call is to be transferred to user C in the case where A does not already have a call to user C. 

If user A does not provide sufficient information to enable a call to be established to user C, user B may provide 
additional information to identify user C and enable the call to be established. 

The generalized model for Single Step call Transfer is as shown in figure 4. 




Figure 4: Generalized model for QSIG Single Step Call Transfer 
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Compared with the general model for transfer by consultation, the following differences exist: 

• entity A* replaces entity A (although it has some common functionality); 

• entity B* replaces entity B (although it has some common functionality); 

• entity C* replaces entity C; 

• leg AB* replaces leg AB (but differs only slightly); 

• leg BC* replaces leg BC (but differs only slightly); 

• leg B* replaces Leg B (but differs only slightly); and 

• leg AC does not exist. 

Entities A*, B' and C are located at the PINX serving user A, user B and user C respectively. 

Entity B* may be located at any PINX between entity A* and entity B'. 

Entity C* is always collocated with entity C in the PINX serving user C. This means that the leg between entity C* and 
entity C is internal to the PINX, and therefore the QSIG protocol for this leg does not apply. Only the protocols defined 
in ECMA-300 for legs AB*, BC* and B* apply. 

Where a user is in another network, the role of entity A*, entity B' or the combined entities C*/C' is performed by the 
other network, the gateway PINX or the two in combination. However, from the QSIG point of view the role is 
performed by the gateway PINX. 

6.1 .2 H.450.2 service architecture 

H.450.2 supports two different call transfer services: 

• transfer by consultation (similar to the service supported by ECMA-178); and 

• single step call transfer (similar to the service supported by ECMA-300). 



6.1.2.1 



Transfer by consultation 



The model shown in figure 1 for QSIG call transfer by consultation applies also to ITU-T Recommendation H.450.2. 
Various scenarios arise, depending on gatekeeper involvement. A gatekeeper can act on behalf of user B and/or a 
gatekeeper can act on behalf of user C. 

If no gatekeepers are involved in the call transfer service, entity A is located at user A's endpoint, entities B and B' are 
located at user B's endpoint, and entities C and C are located at user C's endpoint. Legs AB, AC and BC are supported 
by H.450.2 signalling. This is shown in figure 5. 



Endpoint B 



Leg AB 



Endpoint A 



Entity A 




Entity B 


Entity B' 




LegBG 


Entity C 


Entity C 



Leg AG 



Endpoint 
Figure 5: H.450.2 call transfer by consultation model - no gatekeepers involved 
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If a gatekeeper is involved in call transfer on behalf of user B and another gatekeeper is involved on behalf of user C, 
entities B and C are located in the respective gatekeepers and legs AB, AC, CB, B and C are all supported by H.450.2 
signalling. This is shown in figure 6. 



Gatekeeper B 



Gatekeeper 



Endpoint B 




Endpoint C 



Figure 6: H.450.2 call transfer by consultation model - gatekeepers 
involved on behalf of endpoint B and endpoint C 

Models for the cases where only entity B or only entity C is located at a gatekeeper can easily be derived. 

If the same gatekeeper acts on behalf of user B and user C, the model in figure 7 applies. In this case leg BC is internal 
to the gatekeeper and H.450.2 signalling does not apply. 



Endpoint B 



Gatekeeper 



Endpoint A 




Endpoint C 

Figure 7: H.450.2 call transfer by consultation model - single gatekeeper 
involved on behalf of endpoint B and endpoint C 

Where a user is in another network, the role of entity A, entities B and B' or entities C and C is performed by the other 
network, the gateway, or the two in combination. However, from the H.450.2 point of view the role is performed by the 
gateway. 

NOTE: The equivalent of QSIG transfer by join does not exist with H.450.2. Legs AB and AC exist in all 
scenarios (although leg BC can be hidden inside a gatekeeper). 
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6.1 .2.2 Single step call transfer 

For single step call transfer, the general model is as shown in figure 4. 

Unlike the QSIG single step call transfer supplementary service (see clause 6.1.1.2), the H.450.2 single step call transfer 
supplementary service does not enable user B to provide additional information to identify user C if user A did not 
provide sufficient information to enable a call to be established to user C. 

Various scenarios arise, depending on gatekeeper involvement. A gatekeeper can act on behalf of user B and/or a 
gatekeeper can act on behalf of user C. This has impact on the exposure of legs B* and C*, as for transfer by 
consultation. 

If no gatekeepers are involved in single step call transfer, entity A* is located at user A's endpoint, entities B* and B' are 
located at user B's endpoint, and entities C* and C are located at user C's endpoint. Legs AB*, and BC* are supported 
by H.450.2 signalling. This is shown in figure 8. 

Endpoint B 



Leg AB* 



Endpoint A 




Entity B* 


Entity B' 




Leg BC* 


Entity C* 


Entity C 



Endpoint C 

Figure 8: H.450.2 single step call transfer model- no gatekeepers involved 

If a gatekeeper is involved in single step call transfer on behalf of user B and another gatekeeper is involved on behalf 
of user C, entities B* and C*/C' are located in the respective gatekeepers and legs AB*, BC*, and B* are all supported 
by H.450.2 signalling. This is shown in figure 9. 



Gatekeeper B 



Endpoint B 




Gatekeeper 

Figure 9: H.450.2 single step call transfer model - gatekeepers 
involved on behalf of endpoint B and endpoint C 

Models for the cases where only entity B or only entity C is located at a gatekeeper can easily be derived. 

If the same gatekeeper acts on behalf of user B and user C, the model in figure 10 applies. In this case leg BC* is 
internal to the gatekeeper and H.450.2 signalling does not apply. 
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Endpoint B 



Endpoint A 




Figure 10: H.450.2 single step call transfer model - single gatekeeper 
involved on behalf of endpoint B and endpoint C 

In all of these cases of single step call transfer, where a user is in another network, the role of entity A*, entities B* and 
B' or entities C* and C is performed by the other network, the gateway, or the two in combination. However, from the 
H.450.2 point of view the role is performed by the gateway. 

6.1 .3 Scenarios for interworking 



6.1.3.1 



Transfer by consultation 



The models for QSIG and H.450.2 are very similar. This means that the same model is applicable to the 
inter-networking situation between an IP network and a PISN, where one or more of the users involved are served by 
the IP network and the others are served by the PISN. 

Entities A, B' and C are always located in the network of the user concerned, but there is some flexibility in the location 
of entities B and C. Interworking between H.450.2 and QSIG can occur on any of the five legs. For each of the five 
possible points of interworking, two scenarios arise, depending on which side of the interworking point the PISN lies. 

This gives 10 scenarios in total that need to be considered: 

• Scenario ABl: Entity A (PINX A) in PISN, entity B (gatekeeper B or endpoint B) in IP network; 

• Scenario AB2: Entity A (endpoint A) in IP network, entity B (PINX B) in PISN; 

• Scenario ACl: Entity A (PINX A) in PISN, entity C (gatekeeper C or endpoint C) in IP network; 

• Scenario AC2: Entity A (endpoint A) in IP network, entity C (PINX C) in PISN; 

• Scenario BC 1 : Entity B (PINX B) in PISN, entity C (gatekeeper C or endpoint C) in IP network; 

• Scenario BC2: Entity B (gatekeeper B or endpoint B) in IP network, entity C (PINX C) in PISN; 

• Scenario B 1 : Entity B (PINX B) in PISN, entity B' (endpoint B) in IP network; 

• Scenario B2: Entity B (gatekeeper B or endpoint B) in IP network, entity B' (PINX B) in PISN; 

• Scenario CI: Entity C (PINX C) in PISN, entity C (endpoint C) in IP network; and 

• Scenario C2: Entity C (gatekeeper C or endpoint C) in IP network, entity C (PINX C) in PISN. 

With scenarios ABl, AB2, ACl, AC2, BCl and BC2, the PISN is involved in transfer by rerouteing. Since this is only 
an optional part of ECMA-178, these scenarios will not always be available. 

It is possible for more than one scenario to apply to the same call. In particular, because of the triangular situation, 
scenarios ABl, AB2, ACl, AC2, BCl and BC2 will always occur in pairs, e.g. scenarios ABl and ACl if entity A is in 
the PISN and entities B and C are in the IP network. 



ETSI 



19 ETSI TS 101 907 VI .2.1 (2001-08) 

A point of interworking will be implemented in a gateway, which acts as both a H.323 endpoint from the point of view 
of the IP network and an end PINX from the point of view of the PISN. Call transfer entities can be located in the 
gateway but are logically separate from the point of interworking. For example, if user B is in the PISN and users A and 
C are in the IP network, entity B could be located in the gateway on the IP network side of the interworking point, with 
entity B' in the PISN (PINX B). Logically interworking would still be taking place on leg B. 

6.1 .3.2 Single step call transfer 

The models for QSIG and H.450.2 are very similar. This means that the same model is applicable to the 
inter-networking situation between an IP network and a PISN, where one or more of the users involved are served by 
the IP network and the others are served by the PISN. 

Entities A*, B' C* and C are always located in the network of the user concerned, but there is some flexibility in the 
location of entity B*. Interworking between H.450.2 and QSIG can occur on any of legs AB*, BC* and B*. For each of 
the three points of interworking, two scenarios arise, depending on which side of the interworking point the PISN lies. 
This gives six scenarios in total that need to be considered: 

• Scenario AB*1: Entity A* (PINX A) in PISN, entity B* (gatekeeper B* or endpoint B*) in IP network; 

• Scenario AB*2: Entity A* (endpoint A) in IP network, entity B* (PINX B) in PISN; 

• Scenario BC* 1 : Entity B* (PINX B) in PISN, entity C* (gatekeeper C* or endpoint C*) in IP network; 

• Scenario BC*2: Entity B* (gatekeeper B* or endpoint B*) in IP network, combined entities C*/C' (PINX C) in 

PISN; 

• Scenario B* 1 : Entity B* (PINX B) in PISN, entity B' (endpoint B) in IP network; 

• Scenario B*2: Entity B* (gatekeeper B* or endpoint B*) in IP network, entity B' (PINX B) in PISN. 

It is possible for more than one scenario to apply to the same call e.g. scenarios BC* 1 and B* 1 if entity B* is in the 
PISN and entities B' and C* are in the IP network. 

A point of interworking will be implemented in a gateway, which acts as both a H.323 endpoint from the point of view 
of the IP network and an end PINX from the point of view of the PISN. Single step call transfer entities can be located 
in the gateway but are logically separate from the point of interworking. For example, if user B is in the PISN and users 
A and C are in the IP network, entity B* could be located in the gateway on the IP network side of the interworking 
point, with entity B' in the PISN (PINX B). Logically interworking would still be taking place on leg B*. 

6.1 .4 Determination of the location of entities when interworking 
6.1.4.1 Transfer by consultation 

Entities A, B' and C are always located in the network of the user concerned. The locations of entities B and C are 
determined as follows. 

If user A and therefore entity A are in the QSIG network at PINX A and PINX A implements only transfer by join or 
chooses to perform transfer by join, entities B and C will be located at PINX A. Interworking will occur on leg B and/or 
leg C, depending on the location of users B and C. This is shown in figure 11. 
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Figure 11 : Interworking - transfer by join in a PiSN 

If user A and therefore entity A are in the QSIG network at PINX A and PINX A performs transfer by rerouteing, if 
user B is in the IP network the gateway between user A's network and user B's network can choose, on receipt of a 
transfer request from PINX A, whether to provide entity B (in which case interworking occurs on leg B) or to instruct 
the IP network to provide entity B (in which case interworking occurs on leg AB). 

Similarly, if user C is in the IP network the gateway between user A's network and user B's network can choose, on 
receipt of a transfer identify request from PINX A, whether to provide entity C (in which case interworking occurs on 
leg C) or to instruct the IP network to provide entity C (in which case interworking occurs on leg AC). 

Figures 12 and 13 show the two cases where the two gateways make the same decision. If the two gateways make 
different decisions, interworking will also occur on leg BC. The case where entity B is in the PISN and entity C is in the 
IP network is shown in figure 14. The reverse case is not shown. 
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Figure 12: interworking - transfer by rerouteing between PiNX A and 
endpoints B and C in tiie iP network 
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Figure 13: Interworking - transfer by rerouteing between PINX A 

and two gateways 
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Figure 14: Interworking - transfer by rerouteing -between PINX A, entity B 
in a gateway and entity C in the IP network 

If user A and therefore entity A are in the IP network at endpoint A, if user B is in the PISN the gateway between user 
A's network and user B's network can choose, on receipt of a transfer request from endpoint A, whether to provide 
entity B (in which case interworking occurs on leg B) or to instruct the PISN to provide entity B (in which case 
interworking occurs on leg AB). The latter requires support for transfer by rerouteing in the PISN. 
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Similarly, if user C is in the PISN the gateway between user A's network and user C's network can choose, on receipt of 
a transfer identify request from endpoint A, whether to provide entity C (in which case interworking occurs on leg C) or 
to instruct the PISN to provide entity C (in which case interworking occurs on leg AC). The latter requires support for 
transfer by rerouteing in the PISN. If the two gateways make different decisions, interworking will also occur on 
leg BC. 

Figures 15 and 16 show the two cases where the two gateways make the same decision. If the two gateways make 
different decisions (not shown), interworking will also occur on leg BC. 
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Figure 15: Interworking - transfer by rerouteing between endpoint A 
In the IP network and PINXs B and C 
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Figure 16: Interworking - transfer by rerouteing between endpoint A 
In the IP network and two gateways 

In cases where a gateway can choose whether to provide entity B or entity C functionality, the gateway's decision is an 
implementation matter. This can, but need not, take account of the user C or user B respectively. The behaviour of 
entity B or entity C, if provided at the gateway, is outside the scope of the present document and is assumed to be in 
accordance with the requirements of ECMA-178 (when entity A is in the PISN) or in accordance with the requirements 
of ITU-T Recommendation H.450.2 (when entity A is in the IP network). 
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6.1 .4.2 Single step call transfer 

Entities A*, B' C* and C are always located in the network of the user concerned. The location of entity B* is 
determined as follows: 

If user A and therefore entity A* are in the QSIG network at PINX A entity B* may be located at PINX A. 
Interworking will occur on leg B* and/or leg BC*, depending on the location of users B and C. 

If user B is in the IP network, the gateway between user As network and user B's network can choose, on receipt of a 
transfer request from PINX A, whether to provide entity B* (in which case interworking occurs on leg B*) or to instruct 
the IP network to provide entity B* (in which case interworking occurs on leg AB*). 

Figure 17 shows the case where entity B* is provided by the gateway. Figure 18 shows the case where entity B* is 
provided by the IP network. 
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Figure 17: Interworking - single step call transfer in a PISN 
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Figure 18: Interworking - single step call transfer between PINX A and 
endpoints B and C in the IP network 
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Also, in the case where entity B* is provided by the IP network and user C is in the PISN, interworking will also occur 
on leg BC*. This case is not shown. 

If user A and therefore entity A* are in the IP network at endpoint A, if user B is in the PISN the gateway between user 
A's network and user B's network can choose, on receipt of a transfer request from endpoint A, whether to provide 
entity B* (in which case interworking occurs on leg B*) or to instruct the PISN to provide entity B* (in which case 
interworking occurs on leg AB*). These are shown in figures 19 and 20. 
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Figure 19: Interworking - single step call transfer between endpoint A 
in the IP network and two gateways 
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Figure 20: Interworking - single step call transfer between endpoint A 
in the IP network and PINXs B and C 

Also, in the case where entity B* is provided by the PISN and user C is in the IP network, interworking will also occur 
on leg BC*. This case is not shown. 

In cases where a gateway can choose whether to provide entity B* functionality, the gateway's decision is an 
implementation matter. This can, but need not, take account of the location of user C. The behaviour of entity B*, if 
provided at the gateway, is outside the scope of the present document and is assumed to be in accordance with the 
requirements of ECMA-300 (when entity A* is in the PISN) or in accordance with the requirements of ITU-T 
Recommendation H.450.2 (when entity A* is in the IP network). 
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6.2 Service architecture for activation, deactivation and 
interrogation 



6.2.1 QSIG service architecture 

6.2.1 .1 ECMA-1 78 service architecture 

Not applicable. 

6.2.1 .2 ECMA-300 service architecture 

Not applicable. 

6.2.2 H.450.2 service architecture 

Not applicable. 

6.2.3 Scenarios for interworking 

Not applicable. 



7 Protocol interworking - General requirements 

Protocol interworking between H.323 and QSIG for call transfer supplementary services shall be in accordance with 
ECMA-307, as modified by the requirements of clauses 8 and 9. 

When transmitting an APDU in one protocol as a result of receiving the corresponding APDU in the other protocol, the 
mapping of elements in the received APDU to corresponding elements in the transmitted APDU shall be in accordance 
with ECMA-307. 



8 Protocol interworking - Messages and APDUs 

In the rules specified below for the different scenarios, the following shall apply: 

1) If the required action is to transmit a QSIG or H.323 FACILITY message but the call state does not permit a 
FACILITY message to be sent at that time, the action to be taken is an implementation matter. 

2) If the required action is to include an APDU in a transmitted QSIG or H.323 message conditional upon that 
message being transmitted and that message is not to be transmitted (owing to basic call interworking 
considerations), the action to be taken is an implementation matter. 

Annex B shows in diagrammatic form some typical message sequences for some of the scenarios identified in the 
present document. 
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8.1 



Scenario AB1 



A gateway that supports scenario ABl shall behave in accordance with the rules of table 1, by carrying out the required 
action when a given condition occurs. Each condition applies to the receipt of a QSIG message from entity A, or receipt 
of a H.323 message from entity B. 

Table 1 : Message and APDU handling requirements for scenario AB1 



Rule 


Condition 


Required action 


1 


Receipt of a QSIG FACILITY message containing a 
QSIG callTransferlnitiate invoke APDU wliile tlie QSIG 
call is in the active state. 


Transmit a H.323 FACILITY message containing a 
H.323 callTransferlnitiate invoke APDU if the H.323 call 
state permits. 


2 


Receipt of a H.323 RELEASE CQIVIPLETE message 
containing a H.323 callTransferlnitiate return result 
APDU in response to a H.323 callTransferlnitiate 
invoke APDU. 


If a QSIG DISCQNNECT message is to be transmitted, 
include in the QSIG DISCQNNECT message a QSIG 
callTransferlnitiate return result APDU. 


3 


Receipt of a H.323 FACILITY message containing a 
H.323 callTransferlnitiate return error APDU in 
response to a H.323 callTransferlnitiate invoke APDU. 


Transmit a QSIG FACILITY message containing a 
QSIG callTransferlnitiate return error APDU if the QSIG 
call state permits. 



8.2 



Scenario AB2 



A gateway that supports scenario AB2 shall behave in accordance with the rules of table 2, by carrying out the required 
action when a given condition occurs. Each condition applies to the receipt of a H.323 message from entity A, or receipt 
of a QSIG message from entity B. 

Table 2: Message and APDU handling requirements for scenario AB2 



Rule 


Condition 


Required action 


1 


Receipt of a H.323 FACILITY message containing a 
H.323 callTransferlnitiate invoke APDU while the 
H.323 call is in the active state. 


If the callldentity element in the 

H.323 callTransferlnitiate invoke APDU is not empty, 

transmit a QSIG FACILITY message containing a 

QSIG callTransferlnitiate invoke APDU if the QSIG call 

state permits. 

If the callldentity element in the 

H.323 callTransferlnitiate invoke APDU is empty, refer 

to the rules in 8.12, or reject the request if single step 

call transfer is not supported. 


2 


Receipt of a QSIG DISCQNNECT message containing 
a QSIG callTransferlnitiate return result APDU in 
response to a QSIG callTransferlnitiate invoke APDU. 


If a H.323 RELEASE CQMPLETE message is to be 
transmitted, include in the H.323 RELEASE 
CQMPLETE message a H.323 callTransferlnitiate 
return result APDU. 


3 


Receipt of a QSIG FACILITY message containing a 
QSIG callTransferlnitiate return error APDU in 
response to a QSIG callTransferlnitiate invoke APDU. 


Transmit a H.323 FACILITY message containing a 
H.323 callTransferlnitiate return error APDU if the 
H.323 call state permits. 



ETSI 



27 



ETSI TS 101 907 VI .2.1 (2001-08) 



8.3 



Scenario AC1 



A gateway that supports scenario ACl shall behave in accordance with the rules of table 3, by carrying out the required 
action when a given condition occurs. Each condition applies to the receipt of a QSIG message from entity A, or receipt 
of a H.323 message from entity C. 

Table 3: Message and APDU handling requirements for scenario AC1 



Rule 


Condition 


Required action 


1 


Receipt of a QSIG FACILITY message containing a 
QSIG callTransferldentify invoke APDU wliile tlie 
QSIG call is either in the call received state or in the 
active state. 


Transmit a H.323 FACILITY message containing a 
H.323 callTransferldentify invoke APDU if the 
H.323 call state permits. 


2 


Receipt of a H.323 FACILITY message containing a 
H.323 callTransferldentify return result APDU in 
response to a H.323 callTransferldentify invoke APDU. 


Transmit a QSIG FACILITY message containing a 
QSIG callTransferldentify return result APDU if the 
QSIG call state permits. 


3 


Receipt of a QSIG FACILITY message containing a 
QSIG callTransferAbandon invoke APDU. 


Transmit a H.323 FACILITY message containing a 
H.323 callTransferAbandon invoke APDU if the 
H.323 call state permits. 


4 


Receipt of a H.323 FACILITY message containing a 
H.323 callTransferldentify return error APDU in 
response to a H.323 callTransferldentify invoke APDU. 


Transmit a QSIG FACILITY message containing a 
QSIG callTransferldentify return error APDU if the 
QSIG call state permits. 



8.4 



Scenario AC2 



A gateway that supports scenario AC2 shall behave in accordance with the rules of table 4, by carrying out the required 
action when a given condition occurs. Each condition applies to the receipt of a H.323 message from entity A, or receipt 
of a QSIG message from entity C. 

Table 4: Message and APDU handling requirements for scenario AC2 



Rule 


Condition 


Required action 


1 


Receipt of a H.323 FACILITY message containing a 
H.323 callTransferldentify invoke APDU while the 
H.323 call is either in the call received state or in the 
active state. 


Transmit a QSIG FACILITY message containing a 
QSIG callTransferldentify invoke APDU if the QSIG 
call state permits. 


2 


Receipt of a QSIG FACILITY message containing a 
QSIG callTransferldentify return result APDU in 
response to a QSIG callTransferldentify invoke APDU. 


Transmit a H.323 FACILITY message containing a 
H.323 callTransferldentify return result APDU if the 
H.323 call state permits. 


3 


Receipt of a H.323 FACILITY message containing a 
H.323 callTransferAbandon invoke APDU. 


Transmit a QSIG FACILITY message containing a 
QSIG callTransferAbandon invoke APDU if the QSIG 
call state permits. 


4 


Receipt of a QSIG FACILITY message containing a 
QSIG callTransferldentify return error APDU in 
response to a QSIG callTransferldentify invoke APDU. 


Transmit a H.323 FACILITY message containing a 
H.323 callTransferldentify return error APDU if the 
H.323 call state permits. 
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8.5 



Scenario BC1 



A gateway that supports scenario BCl shall behave in accordance with the rules of table 5, by carrying out the required 
action when a given condition occurs. Each condition applies to the receipt of a QSIG message from entity B, or receipt 
of a H.323 message from entity C. 

Table 5: Message and APDU handling requirements for scenario BC1 



Rule 


Condition 


Required action 


1 


Receipt of a QSIG SETUP message containing a 
QSIG callTransferSetup invoke APDU. 


If a H.323 SETUP message is to be transmitted, 
include in the H.323 SETUP message a 
H.323 callTransferSetup invoke APDU. If the QSIG 
SETUP message also contains a QSIG 
callTransferUpdate invoke APDU, include a 
H.323 callTransferUpdate invoke APDU in the 
H.323 SETUP message. 


2 


Receipt of a H.323 ALERTING message containing a 
H.323 callTransferSetup return result APDU in 
response to a H.323 callTransferSetup invoke APDU. 


If a QSIG ALERTING message is to be transmitted, 
include in the QSIG ALERTING message a QSIG 
callTransferSetup return result APDU. If the 
H.323 ALERTING message also contains a 
H.323 callTransferUpdate invoke APDU, include a 
QSIG callTransferUpdate invoke APDU in the QSIG 
ALERTING message. 


3 


Receipt of a H.323 CQNNECT message containing a 
H.323 callTransferSetup return result APDU in 
response to a H.323 callTransferSetup invoke APDU. 


If a QSIG CQNNECT message is to be transmitted, 
include in the QSIG CQNNECT message a QSIG 
callTransferSetup return result APDU. If the 
H.323 CQNNECT message also contains a 
H.323 callTransferUpdate invoke APDU, include a 
QSIG callTransferUpdate invoke APDU in the QSIG 
CQNNECT message. 


4 


Receipt of a QSIG FACILITY message containing a 
QSIG subaddressTransfer invoke APDU. 


Transmit a H.323 FACILITY message containing a 
H.323 subaddressTransfer invoke APDU if the 
H.323 call state permits. 


5 


Receipt of a H.323 FACILITY message containing a 
H.323 subaddressTransfer invoke APDU. 


Transmit a QSIG FACILITY message containing a 
QSIG subaddressTransfer invoke APDU if the QSIG 
call state permits. 


6 


Receipt of a H.323 RELEASE CQMPLETE message 
containing a H.323 callTransferSetup return error 
APDU in response to a H.323 callTransferSetup invoke 
APDU. 


If a QSIG DISCQNNECT message is to be 
transmitted, include in the QSIG DISCQNNECT 
message a QSIG callTransferSetup return error 
APDU. 
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8.6 



Scenario BC2 



A gateway that supports scenario BC2 shall behave in accordance with the rules of table 6, by carrying out the required 
action when a given condition occurs. Each condition applies to the receipt of a H.323 message from entity B, or receipt 
of a QSIG message from entity C. 

Table 6: Message and APDU handling requirements for scenario BC2 



Rule 


Condition 


Required action 


1 


Receipt of a H.323 SETUP message containing a 
H.323 callTransferSetup invoke APDU. 


If the callldentity element in the H.323 callTransferSetup 
invoke APDU is not empty, then if a QSIG SETUP 
message is to be transmitted, include in the QSIG 
SETUP message a QSIG callTransferSetup invoke 
APDU. If the H.323 SETUP message also contains a 
H.323 callTransferUpdate invoke APDU, include a QSIG 
callTransferUpdate invoke APDU in the QSIG SETUP 
message. 

If the callldentity element in the H.323 callTransferSetup 
invoke APDU is empty, refer to the rules in clause 8.14, 
or reject the request if single step call transfer is not 
supported. 


2 


Receipt of a QSIG ALERTING message containing a 
QSIG callTransferSetup return result APDU in 
response to a QSIG callTransferSetup invoke APDU. 


If a H.323 ALERTING message is to be transmitted, 

include in the H.323 ALERTING message a 

H.323 callTransferSetup return result APDU. If the QSIG 

ALERTING message also contains a QSIG 

callTransferUpdate invoke APDU, include a 

H.323 callTransferUpdate invoke APDU in the 

H.323 ALERTING message. 


3 


Receipt of a QSIG GQNNECT message containing a 
QSIG callTransferSetup return result APDU in 
response to a QSIG callTransferSetup invoke APDU. 


If a H.323 CQNNECT message is to be transmitted, 

include in the H.323 CQNNECT message a 

H.323 callTransferSetup return result APDU. If the QSIG 

CQNNECT message also contains a QSIG 

callTransferUpdate invoke APDU, include a 

H.323 callTransferUpdate invoke APDU in the 

H.323 CQNNECT message. 


4 


Receipt of a QSIG FACILITY message containing a 
QSIG subaddressTransfer invoke APDU. 


Transmit a H.323 FACILITY message containing a H.323 
subaddressTransfer invoke APDU if the H.323 call state 
permits. 


5 


Receipt of a H.323 FACILITY message containing a 
H.323 subaddressTransfer invoke APDU. 


Transmit a QSIG FACILITY message containing a QSIG 
subaddressTransfer invoke APDU if the QSIG call state 
permits. 


6 


Receipt of a QSIG call clearing message containing 
a QSIG callTransferSetup return error APDU in 
response to a QSIG callTransferSetup invoke APDU. 


If a H.323 RELEASE CQMPLETE message is to be 
transmitted, include in the H.323 RELEASE CQMPLETE 
message a H.323 callTransferSetup return error APDU. 
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8.7 Scenario B1 

A gateway that supports scenario Bl shall behave in accordance with the rules of table 7, by carrying out the required 
action when a given condition occurs. Each condition applies to the receipt of a QSIG message from entity B, or receipt 
of a H.323 message from entity B'. 

Table 7: Message and APDU handling requirements for scenario B1 



Rule 


Condition 


Required action 


1 


Receipt of a QSIG FACILITY message containing 
a QSIG callTransferComplete invoke APDU. 


Transmit a H.323 FACILITY message containing a 
H.323 callTransferComplete invoke APDU if the H.323 call 
state permits. If the QSIG FACILITY message also 
contains a QSIG callTransferUpdate APDU, then include a 
H.323 callTransferUpdate invoke APDU in the 
H.323 FACILITY message. 


2 


Receipt of a QSIG FACILITY message containing 
a QSIG callTransferUpdate invoke APDU. 


Transmit a H.323 FACILITY message containing a 
H.323 callTransferUpdate invoke APDU if the H.323 call 
state permits. 


3 


Receipt of a H.323 FACILITY message containing 
a H.323 callTransferUpdate invoke APDU. 


Transmit a QSIG FACILITY message containing a QSIG 
callTransferUpdate invoke APDU if the QSIG call state 
permits. 


4 


Receipt of a QSIG FACILITY message containing 
a QSIG subaddressTransfer invoke APDU. 


Transmit a H.323 FACILITY message containing a 
H.323 subaddressTransfer invoke APDU if the H.323 call 
state permits. 


5 


Receipt of a H.323 FACILITY message containing 
a H.323 subaddressTransfer invoke APDU. 


Transmit a QSIG FACILITY message containing a QSIG 
subaddressTransfer invoke APDU if the QSIG call state 
permits. 


6 


Receipt of a QSIG FACILITY message containing 
a QSIG callTransferActive invoke APDU. 


Transmit a H.323 FACILITY message containing a 
H.323 callTransferActive invoke APDU if the H.323 call 
state permits. 



8.8 



Scenario B2 



A gateway that supports scenario B2 shall behave in accordance with the rules of table 8, by carrying out the required 
action when a given condition occurs. Each condition applies to the receipt of a QSIG message from entity B', or receipt 
of a H.323 message from entity B. 

Table 8: Message and APDU handling requirements for scenario B2 



Rule 


Condition 


Required action 


1 


Receipt of a H.323 FACILITY message 
containing a H.323 callTransferComplete invoke 
APDU. 


Transmit a QSIG FACILITY message containing a QSIG 
callTransferComplete invoke APDU if the QSIG call state 
permits. If the H.323 FACILITY message also contains a 
H.323 callTransferUpdate APDU, then include a QSIG 
callTransferUpdate invoke APDU in the QSIG FACILITY 
message. 


2 


Receipt of a QSIG FACILITY message containing 
a QSIG callTransferUpdate invoke APDU. 


Transmit a H.323 FACILITY message containing a 
H.323 callTransferUpdate invoke APDU if the H.323 call 
state permits. 


3 


Receipt of a H.323 FACILITY message 
containing a H.323 callTransferUpdate invoke 
APDU. 


Transmit a QSIG FACILITY message containing a QSIG 
callTransferUpdate invoke APDU if the QSIG call state 
permits. 


4 


Receipt of a QSIG FACILITY message containing 
a QSIG subaddressTransfer invoke APDU. 


Transmit a H.323 FACILITY message containing a 
H.323 subaddressTransfer invoke APDU if the 
H.323 call state permits. 


5 


Receipt of a H.323 FACILITY message 
containing a H.323 subaddressTransfer invoke 
APDU. 


Transmit a QSIG FACILITY message containing a QSIG 
subaddressTransfer invoke APDU if the QSIG call state 
permits. 


6 


Receipt of a H.323 FACILITY message 
containing a H.323 callTransferActive invoke 
APDU. 


Transmit a QSIG FACILITY message containing a QSIG 
callTransferActive invoke APDU if the H.323 call state 
permits. 
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8.9 



Scenario C1 



A gateway that supports scenario CI shall behave in accordance with the rules of table 9, by carrying out the required 
action when a given condition occurs. Each condition applies to the receipt of a QSIG message from entity C, or receipt 
of a H.323 message from entity C. 

Table 9: Message and APDU handling requirements for scenario CI 



Rule 


Condition 


Required action 


1 


Receipt of a QSIG FACILITY message containing 
a QSIG callTransferComplete invoke APDU. 


Transmit a H.323 FACILITY message containing a 
H.323 callTransferComplete invoke APDU if the 
H.323 call state permits. If the QSIG FACILITY message 
also contains a QSIG callTransferUpdate APDU, then 
include a H.323 callTransferUpdate invoke APDU in the 
H.323 FACILITY message. 


2 


Receipt of a QSIG FACILITY message containing 
a QSIG callTransferUpdate invoke APDU. 


Transmit a H.323 FACILITY message containing a 
H.323 callTransferUpdate invoke APDU if the H.323 call 
state permits. 


3 


Receipt of a H.323 FACILITY message containing 
a H.323 callTransferUpdate invoke APDU. 


Transmit a QSIG FACILITY message containing a QSIG 
callTransferUpdate invoke APDU if the QSIG call state 
permits. 


4 


Receipt of a QSIG FACILITY message containing 
a QSIG subaddressTransfer invoke APDU. 


Transmit a H.323 FACILITY message containing a 
H.323 subaddressTransfer invoke APDU if the H.323 call 
state permits. 


5 


Receipt of a H.323 FACILITY message containing 
a H.323 subaddressTransfer invoke APDU. 


Transmit a QSIG FACILITY message containing a QSIG 
subaddressTransfer invoke APDU if the QSIG call state 
permits. 



8.10 Scenario C2 

A gateway that supports scenario C2 shall behave in accordance with the rules of table 10, by carrying out the required 
action when a given condition occurs. Each condition applies to the receipt of a QSIG message from entity C, or receipt 
of a H.323 message from entity C. 

Table 10: Message and APDU handling requirements for scenario C2 



Rule 


Condition 


Required action 


1 


Receipt of a H.323 FACILITY message containing 
a H.323 callTransferComplete invoke APDU. 


Transmit a QSIG FACILITY message containing a QSIG 
callTransferComplete invoke APDU if the QSIG call state 
permits. If the H.323 FACILITY message also contains a 
H.323 callTransferUpdate APDU, then include a QSIG 
callTransferUpdate invoke APDU in the QSIG FACILITY 
message. 


2 


Receipt of a QSIG FACILITY message containing 
a QSIG callTransferUpdate invoke APDU. 


Transmit a H.323 FACILITY message containing a 
H.323 callTransferUpdate invoke APDU if the H.323 call 
state permits. 


3 


Receipt of a H.323 FACILITY message containing 
a H.323 callTransferUpdate invoke APDU. 


Transmit a QSIG FACILITY message containing a QSIG 
callTransferUpdate invoke APDU if the QSIG call state 
permits. 


4 


Receipt of a QSIG FACILITY message containing 
a QSIG subaddressTransfer invoke APDU. 


Transmit a H.323 FACILITY message containing a 
H.323 subaddressTransfer invoke APDU if the H.323 call 
state permits. 


5 


Receipt of a H.323 FACILITY message containing 
a H.323 subaddressTransfer invoke APDU. 


Transmit a QSIG FACILITY message containing a QSIG 
subaddressTransfer invoke APDU if the QSIG call state 
permits. 
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8.11 Scenario AB*1 

A gateway that supports scenario AB* 1 shall behave in accordance with the rules of table 1 1 , by carrying out the 
required action when a given condition occurs. Each condition applies to the receipt of a QSIG message from entity A*, 
or receipt of a H.323 message from entity B*. 

Table 11 : Message and APDU handling requirements for scenario AB*1 



Rule 


Condition 


Required action 


1 


Receipt of a QSIG FACILITY message containing a 
QSIG ssctlnitiate invoke APDU wliile tine QSIG call is 
in the active state. 


Transmit a H.323 FACILITY message containing a 
H.323 callTransferlnitiate invoke APDU if the 
H.323 call state permits. 


2 


Receipt of a H.323 RELEASE GQMPLETE message 
containing a H.323 callTransferlnitiate return result 
APDU in response to a H.323 callTransferlnitiate 
invoke APDU. 


If a QSIG DISCQNNECT message is to be 
transmitted, include in the QSIG DISCQNNECT 
message a QSIG ssctlnitiate return result APDU. 


3 


Receipt of a H.323 FACILITY message containing a 
H.323 callTransferlnitiate return error APDU in 
response to a H.323 callTransferlnitiate invoke APDU. 


Transmit a QSIG FACILITY message containing a 
QSIG ssctlnitiate return error APDU if the QSIG call 
state permits. 



8.12 Scenario AB*2 

A gateway that supports scenario AB*2 shall behave in accordance with the rules of table 12, by carrying out the 
required action when a given condition occurs. Each condition applies to the receipt of a H.323 message from entity A*, 
or receipt of a QSIG message from entity B*. 

Table 12: Message and APDU handling requirements for scenario AB*2 



Rule 


Condition 


Required action 


1 


Receipt of a H.323 FACILITY message 
containing a H.323 callTransferlnitiate invoke 
APDU while the H.323 call is in the active state. 


If the callldentity element in the H.323 callTransferlnitiate 
invoke APDU is empty, transmit a QSIG FACILITY message 
containing a QSIG ssctlnitiate invoke APDU if the QSIG call 
state permits. 

If callldentity element in the H.323 callTransferlnitiate invoke 
APDU is not empty, refer to the rules in clause 8.2, or reject 
the request if call transfer by consultation is not supported. 


2 


Receipt of a QSIG DISCQNNECT message 
containing a QSIG ssctlnitiate return result 
APDU in response to a QSIG ssctlnitiate invoke 
APDU. 


If a H.323 RELEASE CQMPLETE message is to be 
transmitted, include in the H.323 RELEASE CQMPLETE 
message a H.323 callTransferlnitiate return result APDU. 


3 


Receipt of a QSIG FACILITY message 
containing a QSIG ssctlnitiate return error 
APDU in response to a QSIG ssctlnitiate invoke 
APDU. 


Transmit a H.323 FACILITY message containing a 

H.323 callTransferlnitiate return error APDU if the H.323 call 

state permits. 
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8.13 Scenario BC*1 

A gateway that supports scenario BC*1 shall behave in accordance with the rules of table 13, by carrying out the 
required action when a given condition occurs. Each condition applies to the receipt of a QSIG message from entity B*, 
or receipt of a H.323 message from entity C*. 

Table 13: Message and APDU handling requirements for scenario BC*1 



Rule 


Condition 


Required action 


1 


Receipt of a QSIG SETUP message 
containing a QSIG ssctSetup invoke APDU. 


If a H.323 SETUP message is to be transmitted, include in the 
H.323 SETUP message a H.323 callTransferSetup invoke 
APDU. 


2 


Receipt of a H.323 ALERTING message 
containing a H.323 callTransferSetup return 
result APDU in response to a 
H.323 callTransferSetup invoke APDU. 


Discard the H.323 callTransferSetup return result APDU. If the 
H.323 ALERTING message contains a H.323 
callTransferUpdate invoke APDU, then if a QSIG ALERTING 
message is to be transmitted, include in the QSIG ALERTING 
message a QSIG callTransferUpdate invoke APDU. 


3 


Receipt of a H.323 CQNNECT message 
containing a H.323 callTransferSetup return 
result APDU in response to a 
H.323 callTransferSetup invoke APDU. 


Discard the H.323 callTransferSetup return result APDU. If the 
H.323 CQNNECT message contains a H.323 
callTransferUpdate invoke APDU, then if a QSIG CQNNECT 
message is to be transmitted, include in the QSIG CQNNECT 
message a QSIG callTransferUpdate invoke APDU. 


4 


Receipt of a QSIG FACILITY message 
containing a QSIG subaddressTransfer 
invoke APDU. 


Transmit a H.323 FACILITY message containing a 

H.323 subaddressTransfer invoke APDU if the H.323 call state 

permits. 


5 


Receipt of a H.323 FACILITY message 
containing a H.323 subaddressTransfer 
invoke APDU. 


Transmit a QSIG FACILITY message containing a QSIG 
subaddressTransfer invoke APDU if the QSIG call state 
permits. 


6 


Receipt of a H.323 RELEASE CQMPLETE 
message containing a 
H.323 callTransferSetup return error APDU 
in response to a H.323 callTransferSetup 
invoke APDU. 


Discard the H.323 callTransferSetup return error APDU. 
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8.14 Scenario BC*2 

A gateway that supports scenario BC*2 shall behave in accordance with the rules of table 14, by carrying out the 
required action when a given condition occurs. Each condition applies to the receipt of a H.323 message from entity B*, 
or receipt of a QSIG message from entity C*. 

Table 14: Message and APDU handling requirements for scenario BC*2 



Rule 


Condition 


Required action 


1 


Receipt of a H.323 SETUP message 
containing a H.323 callTransferSetup 
invoke APDU. 


If the callldentity element in the H.323 callTransferSetup invoke 
APDU is empty, then if a QSIG SETUP message is to be 
transmitted, include in the QSIG SETUP message a QSIG 
ssctSetup invoke APDU. 

If callldentity element in the H.323 callTransferSetup invoke 
APDU is not empty, refer to the rules in clause 8.6, or reject the 
request if call transfer by consultation is not supported. 


2 


Receipt of a QSIG ALERTING message in 
response to a QSIG ssctSetup invoke 
APDU. 


If a H.323 ALERTING message is to be transmitted, include in 

the H.323 ALERTING message a H.323 callTransferSetup 

return result APDU. If the QSIG ALERTING message contains a 

QSIG callTransferUpdate invoke APDU, include a 

H.323 callTransferUpdate invoke APDU in the H.323 ALERTING 

message. 


3 


Receipt of a QSIG CQNNECT message in 
response to a QSIG ssctSetup invoke 
APDU. 


If a H.323 CQNNECT message is to be transmitted and a 
H.323 callTransferSetup return result APDU has not already 
been included in a H.323 ALERTING message, then include in 
the H.323 CQNNECT message a H.323 callTransferSetup return 
result APDU. If the QSIG CONNECT message contains a QSIG 
callTransferUpdate invoke APDU, include a 
H.323 callTransferUpdate invoke APDU in the H.323 CQNNECT 
message. 


4 


Receipt of a QSIG FACILITY message 
containing a QSIG subaddressTransfer 
invoke APDU. 


Transmit a H.323 FACILITY message containing a 

H.323 subaddressTransfer invoke APDU if the H.323 call state 

permits. 


5 


Receipt of a H.323 FACILITY message 
containing a H.323 subaddressTransfer 
invoke APDU. 


Transmit a QSIG FACILITY message containing a QSIG 
subaddressTransfer invoke APDU if the QSIG call state permits. 


6 


Receipt of a QSIG call clearing message 
in response to a QSIG ssctSetup invoke 
APDU. 


If a H.323 RELEASE CQMPLETE message is to be transmitted, 
include in the H.323 RELEASE CQMPLETE message a 
H.323 callTransferSetup return error APDU. 
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8.15 Scenario B*1 

A gateway that supports scenario B* 1 shall behave in accordance with the rules of table 15, by carrying out the required 
action when a given condition occurs. Each condition applies to the receipt of a QSIG message from entity B*, or 
receipt of a H.323 message from entity B'. 

Table 15: Message and APDU handling requirements for scenario B*1 



Rule 


Condition 


Required action 


1 


Receipt of a QSIG FACILITY message 
containing a QSIG callTransferComplete 
invoke APDU. 


Transmit a H.323 FACILITY message containing a 
H.323 callTransferComplete invoke APDU if the H.323 call 
state permits. If the QSIG FACILITY message also 
contains a QSIG callTransferUpdate APDU, then include a 
H.323 callTransferUpdate invoke APDU in the 
H.323 FACILITY message. 


2 


Receipt of a QSIG FACILITY message 
containing a QSIG ssctPostDial invoke APDU. 


Discard the QSIG ssctPostDial invoke APDU. If further 
APDUs are present, then subject to rules 3, 5 and 7, 
transmit a H.323 FACILITY message if the H.323 call 
state permits. 


3 


Receipt of a QSIG FACILITY message 
containing a QSIG callTransferUpdate invoke 
APDU. 


Transmit a H.323 FACILITY message containing a 
H.323 callTransferUpdate invoke APDU if the H.323 call 
state permits. 


4 


Receipt of a H.323 FACILITY message 
containing a H.323 callTransferUpdate invoke 
APDU. 


Transmit a QSIG FACILITY message containing a QSIG 
callTransferUpdate invoke APDU if the QSIG call state 
permits. 


5 


Receipt of a QSIG FACILITY message 
containing a QSIG subaddressTransfer invoke 
APDU. 


Transmit a H.323 FACILITY message containing a 
H.323 subaddressTransfer invoke APDU if the H.323 call 
state permits. 


6 


Receipt of a H.323 FACILITY message 
containing a H.323 subaddressTransfer invoke 
APDU. 


Transmit a QSIG FACILITY message containing a QSIG 
subaddressTransfer invoke APDU if the QSIG call state 
permits. 


7 


Receipt of a QSIG FACILITY message 
containing a QSIG callTransferActive invoke 
APDU. 


Transmit a H.323 FACILITY message containing a 
H.323 callTransferActive invoke APDU if the H.323 call 
state permits. 
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8.16 Scenario B*2 

A gateway that supports scenario B*2 shall behave in accordance with the rules of table 16, by carrying out the required 
action when a given condition occurs. Each condition applies to the receipt of a QSIG message from entity B*, or 
receipt of a H.323 message from entity B'. 

Table 16: Message and APDU handling requirements for scenario B*2 



Rule 


Condition 


Required action 


1 


Receipt of a H.323 FACILITY message containing 
a H.323 callTransferComplete invoke APDU. 


Transmit a QSIG FACILITY message containing a QSIG 
callTransferComplete invoke APDU if the QSIG call state 
permits. If the H.323 FACILITY message also contains a 
H.323 callTransferUpdate APDU, then include a QSIG 
callTransferUpdate invoke APDU in the QSIG FACILITY 
message. 


2 


Receipt of a QSIG FACILITY message containing 
a QSIG callTransferUpdate invoke APDU. 


Transmit a H.323 FACILITY message containing a 
H.323 callTransferUpdate invoke APDU if the H.323 call 
state permits. 


3 


Receipt of a H.323 FACILITY message containing 
a H.323 callTransferUpdate invoke APDU. 


Transmit a QSIG FACILITY message containing a QSIG 
callTransferUpdate invoke APDU if the QSIG call state 
permits. 


4 


Receipt of a QSIG FACILITY message containing 
a QSIG subaddressTransfer invoke APDU. 


Transmit a H.323 FACILITY message containing a 
H.323 subaddressTransfer invoke APDU if the 
H.323 call state permits. 


5 


Receipt of a H.323 FACILITY message containing 
a H.323 subaddressTransfer invoke APDU. 


Transmit a QSIG FACILITY message containing a QSIG 
subaddressTransfer invoke APDU if the QSIG call state 
permits. 


6 


Receipt of a H.323 FACILITY message containing 
a H.323 callTransferActive invoke APDU. 


Transmit a QSIG FACILITY message containing a QSIG 
callTransferActive invoke APDU if the H.323 call state 
permits. 



9 Protocol interworking - Content of APDUs 

This clause contains the requirements for the mapping of elements that are not covered by the general requirements in 
clause 7. 

Rules are provided only for elements that are mandatory in at least one of the protocols. Optional elements may be 
discarded if received. 

9.1 APDU content mapping from QSIG to H.323 

9.1 .1 QSIG ssctlnitiate invoke APDU mapping to H.323 callTransferlnitiate 
invoke APDU 

A gateway that supports scenario AB*1, when transmitting a H.323 callTransferlnitiate invoke APDU as a result of 
receiving a QSIG ssctlnitiate invoke APDU, shall map elements in accordance with table 17. 

Table 17: QSIG ssctlnitiate Invoke APDU mapping to H.323 callTransferlnitiate Invoke APDU 



QSIG element name 

"(M)" denotes mandatory 

element 


H.323 element name 

"(M)" denotes mandatory 

element 


Mapping requirement 


N/A 


call Identity (IVI) 


Encode as empty (size 0) to denote invocation 
of single step call transfer. 


transferredAddress (IVI) 


N/A 


Discard. 


awaitConnect (M) 


N/A 


Discard. 
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9.1 .2 QSIG ssctSetup invoke APDU mapping to H.323 callTransferSetup 
invoke APDU 

A gateway that supports scenario BC*1, when transmitting a H.323 callTransferSetup invoke APDU as a result of 
receiving a QSIG ssctSetup invoke APDU, shall map elements in accordance with table 18. 

Table 18: QSIG ssctSetup invoke APDU mapping to H.323 callTransferSetup invoke APDU 



QSIG element name 

"(M)" denotes mandatory 

element 


H.323 element name 

"(M)" denotes mandatory 

element 


Mapping requirement 


N/A 


call Identity (M) 


Encode as empty (size 0). 



9.2 APDU content mapping from H.323 to QSIG 

9.2.1 H.323 callTransferlnitiate invoke APDU mapping to QSIG ssctlnitiate 
invoke APDU 

A gateway that supports scenario AB*2, when transmitting a QSIG ssctlnitiate invoke APDU as a result of receiving a 
H.323 callTransferlnitiate invoke APDU, shall map elements in accordance with table 19. 

Table 19: H.323 callTransferlnitiate invoke APDU mapping to QSIG ssctlnitiate invoke APDU 



H.323 element name 

"(M)" denotes mandatory 

element 


QSIG element name 

"(M)" denotes mandatory 

element 


Mapping requirement 


call Identity (M) 


N/A 


Discard. 


N/A 


transferredAddress (M) 


The availability of the information to be included in this 
element will depend on implementation. 
Include the information if available or include the 
indication "notAvailableDueTolnterworking" if the 
information is not available. 


N/A 


awaitConnect 


Encode with the value set to FALSE, i.e. release the 
original call on receipt of the ALERTING message. 



9.2.2 H.323 callTransferSetup invoke APDU mapping to QSIG ssctSetup 
invoke APDU 

A gateway that supports scenario BC*2, when transmitting a QSIG ssctSetup invoke APDU as a result of receiving a 
H.323 callTransferSetup invoke APDU, shall map elements in accordance with table 20. 

Table 20: H.323 callTransferSetup invoke APDU mapping to QSIG ssctSetup invoke APDU 



H.323 element name 

"(M)" denotes mandatory 

element 


QSIG element name 

"(M)" denotes mandatory 

element 


Mapping requirement 


callldentity (M) 


N/A 


Discard. 
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Annex A (normative): 

Implementation Conformance Statement (ICS) proforma 



Notwithstanding the provisions of the copyright clause related to the text of the present document, ETSI grants that 
users of the present document may freely reproduce the ICS proforma in this annex so that it can be used for its 
intended purposes and may further publish the completed ICS. 



A.1 Introduction 

The supplier of an implementation which is claimed to conform to the present document shall complete the following 
Implementation Conformance Statement (ICS) proforma. 

A completed ICS proforma is the ICS for the implementation in question. The ICS is a statement of which capabilities 
and options have been implemented for a given specification. 

The ICS can have a number of uses, including use: 

• by the implementor, as a check list for implementations to reduce the risk of unintended non-conformance, 
e.g. through oversight; 

• by the supplier and acquirer, or potential acquirer, of the implementation, as a detailed indication of the 
capabilities of the implementation, stated relative to the common basis for understanding provided by the 
Standard's ICS proforma; 

• by the user or potential user of the implementation, as a basis for initially checking the possibility of 
interworking with another implementation - while interworking can never be guaranteed, failure to interwork can 
often be predicted from incompatible ICS; 

• by a tester, as the basis for selecting appropriate tests against which to assess the claim for conformance of the 
implementation. 



A.2 Instructions for completing the ICS proforma 
A.2.1 General structure of the ICS proforma 

The ICS proforma is a fixed format questionnaire divided into clauses each containing a group of individual items. Each 
item is identified by an item reference, the description of the item (question to be answered), and the reference(s) to the 
clause(s) that specifies (specify) the item in the main body of the present document. 

The "Conditions for Status" column contains a specification, if appropriate, of the predicate upon which a conditional 
status is based. The indication of an item reference in this column indicates a simple-predicate condition (support of this 
item is dependent on the support marked for the referenced item). 

The "Status" column indicates whether an item is applicable and if so whether support is mandatory or optional. The 
following terms are used: 

I irrelevant or out-of-scope - this capability is outside the scope of the standard to which this ICS 

proforma applies and is not subject to conformance testing in this context; 

M mandatory (the capability is required for conformance to the standard); 

N/A not applicable - in the given context, it is impossible to use the capability; no answer in the support 

column is required; 

O optional (the capability is not required for conformance to the standard, but if the capability is 

implemented it is required to conform to the specification in the present document); 
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0.<n> qualified optional - in this case, <n> is an integer that identifies a unique group of related optional 

items; if no additional qualification is indicated, the support of at least one of the optional items is 
required for conformance to the present document; otherwise, the qualification and logic of the 
selection among the optional items is defined below the table explicitly; 

X excluded or prohibited - there is a requirement not to use this capability in a given context. 

Answers to the questionnaire items are to be provided in the "Support" column, by simply marking an answer to 
indicate a restricted choice (Yes, No or N/A). In specific cases, the indication of explicit values may be requested. 
Where a support column box is left blank, no answer is required. 

If a "prerequisite line" (see clause A.2.4) is used after a clause heading or table title, and its predicate is false, no answer 
is required for the whole clause or table, respectively. 

A.2.2 Additional information 

Items of additional information allow a supplier to provide further information intended to assist the interpretation of 
the ICS. It is not intended or expected that a large quantity will be supplied, and an ICS can be considered complete 
without any such information. Examples might be an outline of the ways in which a (single) implementation can be set 
up to operate in a variety of environments and configurations. 

References to items of additional information may be entered next to any answer in the questionnaire, and may be 
included in items of exception information. 



A.2.3 Exception information 



It may occasionally happen that a supplier will wish to answer an item with mandatory or prohibited status (after any 
conditions have been applied) in a way that conflicts with the indicated requirement. No pre-printed answer will be 
found in the Support column for this. Instead, the supplier is required to write into the support column an x.<i> 
reference to an item of exception information, and to provide the appropriate rationale in the Exception item itself. 

An implementation for which an exception item is required in this way does not conform to the present document. A 
possible reason for the situation described above is that a defect in the standard has been reported, a correction for 
which is expected to change the requirement not met by the implementation. 

A.2.4 Further indications of the ICS proforma tables 

In addition to the columns of a table, the following information may be indicated: 

"Prerequisite line" 

A prerequisite line after a clause heading or table title indicates that the whole clause or the whole table is not required 

to be completed if the predicate is false. 

"Qualification" 

At the end of a table, a detailed qualification for a group of optional items may be indicated, as specified in the 

description of the status "qualified optional" in clause A.2.1. 

"Comments" 

This box at the end of a table allows a supplier to enter any comments to that table. Comments may also be provided 

separately (without using this box). 
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A.3 Identification of the implementation 



A.3.1 Implementation identification 



Supplier (see note 1) 




Contact point for queries about tlie ICS 
(see note 1 ) 




Implementation Name(s) and Version(s) 
(see notes 1 and 2) 




Other information necessary for full identification - 
e.g. name(s) and version(s) for machines and/or 
operating systems; System name(s) 




NOTE 1 : Only the first three items are required for all implementations; other information may be completed as 

appropriate in meeting the requirement for full identification. 
NOTE 2: The terms Name and Version should be interpreted appropriately to correspond with a suppliers 

terminology (e.g. Type, Series, Model). 



A.3. 2 Specification for which this ICS applies 



Title 


Corporate Telecommunication Networks (CN) - Signalling 
interworking between OSIG and H.323 - Call Transfer 
supplementary services 


Version 


1.2.1 


Corrigenda Implemented (if applicable) 




Addenda Implemented (if applicable) 




Amendments Implemented (if applicable) 




Have any exception items been required ? 


No[ ] Yes[ ] 

(The answer Yes means that the implementation does not 

conform to the present document) (see note) 


Date of Statement 




NOTE: In this case, an explanation shall be given of the nature of non-conformance either below or on a 
separate sheet of paper. 
Nature of non-conformance (if applicable): 



A.4 Major capabilities 



Table A.1 : Major capabilities 



Item 


Question: 
Does the implementation... 


Conditions for status 


Status 


Reference 


Support 


MCI 


support transfer by consultation? 




0.1 




[ ]Yes [ ]No 


MC2 


support single step call transfer? 




0.1 




[ ]Yes [ ]No 


MC3 


support OSIG transfer by join? 


MCI 


M 


ECMA-178 


[]Yes 


MC4 


support OSIG transfer by 
rerouteing? 


MCI 





ECMA-178 


[ ]Yes [ ]No 


MC5 


support OSIG single step call 
transfer? 


MC2 


M 


ECMA-300 


[]Yes 


MC6 


support H.450.2 transfer by 
consultation? 


MCI 


M 


H.450.2 


[]Yes 


MC7 


support H.450.2 Single Step call 
transfer? 


MC2 


M 


H.450.2 


[]Yes 


MC8 


support provision of entity B for 
handling transfer by rerouteing 
requests received from the PISN? 


MC4 





6.1.4.1 


[ ]Yes [ ]No 
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Item 


Question: 
Does the implementation... 


Conditions for status 


Status 


Reference 


Support 


MC9 


support provision of entity C for 
liandling transfer by rerouteing 
identify requests from tlie PISN? 


MC4 





6.1.4.1 


[ ]Yes [ ]No 


MC10 


support provision of entity B for 
liandling transfer by consultation 
requests received from the IP 
network? 


MC6 AND MC4 
MC6 AND NOT MC4 




M 


6.1.4.1 


[ ]Yes [ ]No 
[]Yes 


MC11 


support provision of entity C for 
liandling transfer by consultation 
requests received from the IP 
network? 


MC6 AND MC4 
MC6 AND NOT MC4 




M 


6.1.4.1 


[ ]Yes [ ]No 
[]Yes 


MC12 


support provision of entity B* for 
handling single step call transfer 
requests received from the PISN? 


MC2 





6.1.4.2 


[ ]Yes [ ]No 


MC13 


support provision of entity C* for 
handling single step call transfer 
requests from the PISN? 


MC2 





6.1.4.2 


[ ]Yes [ ]No 


MC14 


support provision of entity B* for 
handling single step call transfer 
requests received from the IP 
network? 


MC2 





6.1.4.2 


[ ]Yes [ ]No 


MC15 


support provision of entity C* for 
handling single step call transfer call 
establishment requests received 
from the IP network? 


MC2 





6.1.4.2 


[ ]Yes [ ]No 


MC16 


support scenario AB1 ? 


MC4 AND MC8 
MC4 AND NOT MC8 




M 


6.1.3.1 


[ ]Yes [ ]No 
[]Yes 


MC17 


support scenario AB2? 


MC4ANDMC10 
MC4ANDNOTMC10 




M 


6.1.3.1 


[ ]Yes [ ]No 
[]Yes 


MC18 


support scenario AC1 ? 


MC4 AND MC9 
MC4 AND NOT MC9 




M 


6.1.3.1 


[ ]Yes [ ]No 
[]Yes 


MC19 


support scenario AC2? 


MC4 AND MC1 1 
MC4 AND NOT MC1 1 




M 


6.1.3.1 


[ ]Yes [ ]No 
[]Yes 


MC20 


support scenario BC1? 


MC4 


M 


6.1.3.1 


[]Yes 


MC21 


support scenario BC2? 


MC4 


M 


6.1.3.1 


[]Yes 


MC22 


support scenario B1 ? 


MC1 


M 


6.1.3.1 


[]Yes 


MC23 


support scenario B2? 


MC1 


M 


6.1.3.1 


[]Yes 


MC24 


support scenario C1? 


MC1 


M 


6.1.3.1 


[]Yes 


MC25 


support scenario C2? 


MC1 


M 


6.1.3.1 


[]Yes 


MC26 


support scenario AB*1 ? 


MC2ANDMC12 
MC2ANDNOTMC12 




M 


6.1.3.2 


[ ]Yes [ ]No 
[]Yes 


MC27 


support scenario AB*2? 


MC2ANDMC14 
MC2ANDNOTMC14 




M 


6.1.3.2 


[ ]Yes [ ]No 
[]Yes 


MC28 


support scenario BC*1 ? 


MC2ANDMC13 
MC2ANDNOTMC13 




M 


6.1.3.2 


[ ]Yes [ ]No 
[]Yes 


MC29 


support scenario BC*2? 


MC2ANDMC15 
MC2ANDNOTMC15 




M 


6.1.3.2 


[ ]Yes [ ]No 
[]Yes 


MC30 


support scenario B*1? 


MC2 


M 


6.1.3.2 


[]Yes 


MC31 


support scenario B*2? 


MC2 


M 


6.1.3.2 


[]Yes 


Comments: 





A.5 General requirements 

Table A.2: General requirements for protocol interworking 



Item 


Question: 
Does tlie implementation... 


Conditions for 
status 


Status 


Reference 


Support 


GR1 


perform protocol interworking in accordance 
with ECMA-307? 




M 


7 


[]Yes 


Comments: 
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A.6 Message and APDU handling 

A.6.1 Message and APDU handling for scenario AB1 

Table A.3: Message and APDU handling for scenario AB1 



Item 


Question: 
Does the implementation... 


Conditions for 
status 


Status 


Reference 


Support 


MAB1 1 


behave in accordance with rule 1 for 
scenario AB1? 


MC16 


M 


8.1 


[]Yes 


MAB1 2 


behave in accordance with rule 2 for 
scenario AB1? 


MC16 


M 


8.1 


[]Yes 


MAB1 3 


behave in accordance with rule 3 for 
scenario AB1? 


MC16 


M 


8.1 


[]Yes 


Comments: 



A.6. 2 Message and APDU handling for scenario AB2 

Table A.4: IVIessage and APDU handling for scenario AB2 



Item 


Question: 
Does tlie implementation... 


Conditions for 
status 


Status 


Reference 


Support 


MAB2 1 


behave in accordance with rule 1 for 
scenario AB2? 


MCI 7 


M 


8.2 


[]Yes 


MAB2 2 


behave in accordance with rule 2 for 
scenario AB2? 


MCI 7 


M 


8.2 


[]Yes 


MAB2 3 


behave in accordance with rule 3 for 
scenario AB2? 


MCI 7 


M 


8.2 


[]Yes 


Comments: 



A.6. 3 Message and APDU handling for scenario AC1 

Table A.5: IVIessage and APDU handling for scenario AC1 



Item 


Question: 
Does tlie implementation... 


Conditions for 
status 


Status 


Reference 


Support 


MAC1 1 


behave in accordance with rule 1 for 
scenario AC1 ? 


MCI 8 


M 


8.3 


[]Yes 


MAC1 2 


behave in accordance with rule 2 for 
scenario AC1 ? 


MCI 8 


M 


8.3 


[]Yes 


MAC1 3 


behave in accordance with rule 3 for 
scenario AC1 ? 


MCI 8 


M 


8.3 


[]Yes 


MAC1 4 


behave in accordance with rule 4 for 
scenario AC1 ? 


MCI 8 


M 


8.3 


[]Yes 


Comments: 
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A.6.4 Message and APDU handling for scenario AC2 

Table A.6: Message and APDU handling for scenario AC2 



Item 


Question: 
Does the implementation... 


Conditions for 
status 


Status 


Reference 


Support 


MAC2 1 


behave in accordance with rule 1 for 
scenario AC2? 


MC19 


M 


8.4 


[]Yes 


MAC2 2 


behave in accordance with rule 2 for 
scenario AC2? 


MC19 


M 


8.4 


[]Yes 


MAC2 3 


behave in accordance with rule 3 for 
scenario AC2? 


MC19 


M 


8.4 


[]Yes 


MAC2 4 


behave in accordance with rule 4 for 
scenario AC2? 


MC19 


M 


8.4 


[]Yes 


Comments: 



A.6. 5 IVIessage and APDU handling for scenario BC1 

Table A.7: Message and APDU handling for scenario BC1 



Item 


Question: 
Does tiie implementation... 


Conditions for 
status 


Status 


Reference 


Support 


MBC1 1 


behave in accordance with rule 1 for 
scenario BC1 ? 


MC20 


M 


8.5 


[]Yes 


MBC1 2 


behave in accordance with rule 2 for 
scenario BC1 ? 


MC20 


M 


8.5 


[]Yes 


MBC1 3 


behave in accordance with rule 3 for 
scenario BC1 ? 


MC20 


M 


8.5 


[]Yes 


MBC1 4 


behave in accordance with rule 4 for 
scenario BC1 ? 


MC20 


M 


8.5 


[]Yes 


MBC1 5 


behave in accordance with rule 5 for 
scenario BC1 ? 


MC20 


M 


8.5 


[]Yes 


MBC1 6 


behave in accordance with rule 6 for 
scenario BC1 ? 


MC20 


M 


8.4 


[]Yes 


Comments: 



A.6. 6 IVIessage and APDU handling for scenario BC2 

Table A.8: Message and APDU handling for scenario BC2 



Item 


Question: 
Does tlie implementation... 


Conditions for 
status 


Status 


Reference 


Support 


MBC2 1 


behave in accordance with rule 1 for 
scenario BC2? 


MC21 


M 


8.6 


[]Yes 


MBC2 2 


behave in accordance with rule 2 for 
scenario BC2? 


MC21 


M 


8.6 


[]Yes 


MBC2 3 


behave in accordance with rule 3 for 
scenario BC2? 


MC21 


M 


8.6 


[]Yes 


MBC2 4 


behave in accordance with rule 4 for 
scenario BC2? 


MC21 


M 


8.6 


[]Yes 


MBC2 5 


behave in accordance with rule 5 for 
scenario BC2? 


MC21 


M 


8.6 


[]Yes 


MBC2 6 


behave in accordance with rule 6 for 
scenario BC2? 


MC21 


M 


8.6 


[]Yes 


Comments: 
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A.6.7 Message and APDU handling for scenario B1 

Table A.9: Message and APDU handling for scenario B1 



Item 


Question: 
Does the implementation... 


Conditions for 
status 


Status 


Reference 


Support 


MB1 1 


behave in accordance with rule 1 for 
scenario B1? 


MC22 


M 


8.7 


[]Yes 


MB1 2 


behave in accordance with rule 2 for 
scenario B1? 


MC22 


M 


8.7 


[]Yes 


MB1 3 


behave in accordance with rule 3 for 
scenario B1? 


MC22 


M 


8.7 


[]Yes 


MB1 4 


behave in accordance with rule 4 for 
scenario B1? 


MC22 


M 


8.7 


[]Yes 


MB1 5 


behave in accordance with rule 5 for 
scenario B1? 


MC22 


M 


8.7 


[]Yes 


MB1 6 


behave in accordance with rule 6 for 
scenario B1? 


MC22 


M 


8.7 


[]Yes 


Comments: 



A.6.8 IVIessage and APDU handling for scenario B2 

Table A.10: Message and APDU handling for scenario B2 



Item 


Question: 
Does tlie implementation... 


Conditions for 
status 


Status 


Reference 


Support 


MB2 1 


behave in accordance with rule 1 for 
scenario B2? 


MC23 


M 


8.8 


[]Yes 


MB2 2 


behave in accordance with rule 2 for 
scenario B2? 


MC23 


M 


8.8 


[]Yes 


MB2 3 


behave in accordance with rule 3 for 
scenario B2? 


MC23 


M 


8.8 


[]Yes 


MB2 4 


behave in accordance with rule 4 for 
scenario B2? 


MC23 


M 


8.8 


[]Yes 


MB2 5 


behave in accordance with rule 5 for 
scenario B2? 


MC23 


M 


8.8 


[]Yes 


MB2 6 


behave in accordance with rule 6 for 
scenario B2? 


MC23 


M 


8.8 


[]Yes 


Comments: 



A.6.9 IVIessage and APDU handling for scenario C1 

Table A.11 : Message and APDU handling for scenario C1 



Item 


Question: 
Does tlie implementation... 


Conditions for 
status 


Status 


Reference 


Support 


MC1 1 


behave in accordance with rule 1 for 
scenario C1? 


MC24 


M 


8.9 


[]Yes 


MC1 2 


behave in accordance with rule 2 for 
scenario C1? 


MC24 


M 


8.9 


[]Yes 


MC1 3 


behave in accordance with rule 3 for 
scenario C1? 


MC24 


M 


8.9 


[]Yes 


MC1 4 


behave in accordance with rule 4 for 
scenario C1? 


MC24 


M 


8.9 


[]Yes 


MC1 5 


behave in accordance with rule 5 for 
scenario C1? 


MC24 


M 


8.9 


[]Yes 


Comments: 
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A.6.1 Message and APDU handling for scenario C2 

Table A.12: Message and APDU handling for scenario C2 



Item 


Question: 
Does the Implementation... 


Conditions for 
status 


Status 


Reference 


Support 


MC2 1 


behave in accordance with rule 1 for 
scenario C2? 


MC25 


M 


8.10 


[]Yes 


MC2 2 


behave in accordance with rule 2 for 
scenario C2? 


MC25 


M 


8.10 


[]Yes 


MC2 3 


behave in accordance with rule 3 for 
scenario C2? 


MC25 


M 


8.10 


[]Yes 


MC2 4 


behave in accordance with rule 4 for 
scenario C2? 


MC25 


M 


8.10 


[]Yes 


MC2 5 


behave in accordance with rule 5 for 
scenario C2? 


MC25 


M 


8.10 


[]Yes 


Comments: 



A.6.1 1 IVIessage and APDU handling for scenario AB*1 

Table A.13: Message and APDU handling for scenario AB*1 



Item 


Question: 
Does the Implementation... 


Conditions for 
status 


Status 


Reference 


Support 


MAB*1 1 


behave in accordance with rule 1 for 
scenario AB*1? 


MC26 


M 


8.11 


[]Yes 


MAB*1 2 


behave in accordance with rule 2 for 
scenario AB*1? 


MC26 


M 


8.11 


[]Yes 


MAB*1 3 


behave in accordance with rule 3 for 
scenario AB*1? 


MC26 


M 


8.11 


[]Yes 


Comments: 



A.6.1 2 IVIessage and APDU handling for scenario AB*2 

Table A.14: Message and APDU handling for scenario AB*2 



Item 


Question: 
Does the Implementation... 


Conditions for 
status 


Status 


Reference 


Support 


MAB*2 1 


behave in accordance with rule 1 for 
scenario AB*2? 


MC27 


M 


8.12 


[]Yes 


MAB*2 2 


behave in accordance with rule 2 for 
scenario AB*2? 


MC27 


M 


8.12 


[]Yes 


MAB*2 3 


behave in accordance with rule 3 for 
scenario AB*2? 


MC27 


M 


8.12 


[]Yes 


Comments: 
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A.6.13 Message and APDU handling for scenario BC*1 

Table A.15: Message and APDU handling for scenario BC*1 



Item 


Question: 
Does the implementation... 


Conditions for 
status 


Status 


Reference 


Support 


MBC*1 1 


behave in accordance with rule 1 for 
scenario BC*1? 


MC28 


M 


8.13 


[]Yes 


MBC*1 2 


behave in accordance with rule 2 for 
scenario BC*1? 


MC28 


M 


8.13 


[]Yes 


MBC*1 3 


behave in accordance with rule 3 for 
scenario BC*1? 


MC28 


M 


8.13 


[]Yes 


MBC*1 4 


behave in accordance with rule 4 for 
scenario BC*1? 


MC28 


M 


8.13 


[]Yes 


MBC*1 5 


behave in accordance with rule 5 for 
scenario BC*1? 


MC28 


M 


8.13 


[]Yes 


MBC*1 6 


behave in accordance with rule 6 for 
scenario BC*1? 


MC28 


M 


8.13 


[]Yes 


Comments: 



A.6.14 IVIessage and APDU handling for scenario BC*2 

Table A.16: IVIessage and APDU handling for scenario BC*2 



Item 


Question: 
Does tlie implementation... 


Conditions for 
status 


Status 


Reference 


Support 


W\BC*2 1 


behave in accordance with rule 1 for 
scenario BC*2? 


MC29 


M 


8.14 


[]Yes 


MBC*2 2 


behave in accordance with rule 2 for 
scenario BC*2? 


MC29 


M 


8.14 


[]Yes 


MBC*2 3 


behave in accordance with rule 3 for 
scenario BC*2? 


MC29 


M 


8.14 


[]Yes 


MBC*2 4 


behave in accordance with rule 4 for 
scenario BC*2? 


MC29 


M 


8.14 


[]Yes 


MBC*2 5 


behave in accordance with rule 5 for 
scenario BC*2? 


MC29 


M 


8.14 


[]Yes 


MBC*2 6 


behave in accordance with rule 6 for 
scenario BC*2? 


MC29 


M 


8.14 


[]Yes 


Comments: 
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A.6.1 5 Message and APDU handling for scenario B*1 

Table A.17: Message and APDU handling for scenario B*1 



Item 


Question: 
Does the implementation... 


Conditions for 
status 


Status 


Reference 


Support 


MB*1 1 


behave in accordance with rule 1 for 
scenario B*1? 


MC30 


M 


8.15 


[]Yes 


MB*1 2 


behave in accordance with rule 2 for 
scenario B*1? 


MC30 


M 


8.15 


[]Yes 


MB*1 3 


behave in accordance with rule 3 for 
scenario B*1? 


MC30 


M 


8.15 


[]Yes 


MB*1 4 


behave in accordance with rule 4 for 
scenario B*1? 


MC30 


M 


8.15 


[]Yes 


MB*1 5 


behave in accordance with rule 5 for 
scenario B*1? 


MC30 


M 


8.15 


[]Yes 


MB*1 6 


behave in accordance with rule 6 for 
scenario B*1? 


MC30 


M 


8.15 


[]Yes 


MB*1 7 


behave in accordance with rule 7 for 
scenario B*1? 


MC30 


M 


8.15 


[]Yes 


Comments: 



A.6.1 6 IVIessage and APDU handling for scenario B*2 

Table A.18: IVIessage and APDU handling for scenario B*2 



Item 


Question: 
Does tlie implementation... 


Conditions for 
status 


Status 


Reference 


Support 


MB*2 1 


behave in accordance with rule 1 for 
scenario B*2? 


MC31 


M 


8.16 


[]Yes 


MB*2 2 


behave in accordance with rule 2 for 
scenario B*2? 


MC31 


M 


8.16 


[]Yes 


MB*2 3 


behave in accordance with rule 3 for 
scenario B*2? 


MC31 


M 


8.16 


[]Yes 


MB*2 4 


behave in accordance with rule 4 for 
scenario B*2? 


MC31 


M 


8.16 


[]Yes 


MB*2 5 


behave in accordance with rule 5 for 
scenario B*2? 


MC31 


M 


8.16 


[]Yes 


MB*2 6 


behave in accordance with rule 6 for 
scenario B*2? 


MC31 


M 


8.16 


[]Yes 


Comments: 
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A.7 APDU content mapping 



Table A.19: APDU content mapping 



Item 


Question: 
Does the implementation... 


Conditions for 
status 


Status 


Reference 


Support 


MAPI 


behave in accordance with mapping from 
QSIG ssctlnitiate involve APDUs to 
H.323 callTransferlnitiate invoke APDUs? 


MC26 


M 


9.1.1 


[]Yes 


MAP2 


behave in accordance with mapping from 
QSIG ssctSetup invoke APDUs to 
H.323 callTransferSetup invoke APDUs? 


MC28 


M 


9.1.2 


[]Yes 


MAPS 


behave in accordance with mapping from 
H.323 callTransferlnitiate invoke APDUs to 
QSIG ssctlnitiate invoke APDUs? 


MC27 


M 


9.1.3 


[]Yes 


MAP4 


behave in accordance with mapping from 
H.323 callTransferSetup invoke APDUs to 
QSIG ssctSetup invoke APDUs? 


MG29 


M 


9.1.4 


[]Yes 


Comments: 
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Annex B (informative): 

Example message sequence diagrams 

This annex contains some examples of typical message sequences for some of the scenarios identified in the present 
document. Although the examples shown are typical, other valid message sequences are possible. 

In the figures, the arrows indicate the direction of messages. For each message, only the message name and the 
contained APDU (if applicable) are shown. Other message contents are not shown, in particular for unsuccessful 
attempts at call transfer. The following abbreviations are used: 



.inv 
.res 



invoke APDU 
return result APDU 



B.1 Scenario AB1 or AB*1 



PISN 



Interworking unit 



QSIG FACILITY 

callTransferlnitiate.inv (AB1) 

or ssctlnitiate.inv (AB*1) 



QSIG DISCONNECT 

callTransferlnitiate.res (AB1) or 

ssctlnitiate.res (AB*1) 



QSIG RELEASE 



QSIG RELEASE COMPLETE 



IP network 



H.225.0 FACILITY 
callTransferlnitiate.inv 



H.225.0 RELEASE COMPLETE 
callTransferlnitiate.res 



Figure B.1 : Example of scenario AB1 or AB*1 
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B.2 Scenario AB2 or AB*2 



PISN 



Interworking unit 



H.225.0 FACILITY 
callTransferlnitiate.inv 



H.225.0 RELEASE COMPLETE 
callTransferlnitiate.res 



IP network 



QSIG FACILITY 

callTransferlnitiate.inv (AB2) or 

ssctlnitiate.inv (AB*2) 



QSIG DISCONNECT 

callTransferlnitiate.res (AB2) or 

ssctlnitiate.res (AB*2) 



OSIG RELEASE 



OSIG RELEASE COMPLETE 

Figure B.2: Example of scenario AB2 or AB*2 



B.3 Scenario AC1 



PISN 



Interworking unit 



OSIG FACILITY 
callTransferldentify.inv 



OSIG FACILITY 
callTransferldentify.res 



OSIG DISCONNECT 



OSIG RELEASE 



OSIG RELEASE COMPLETE 



IP network 



H.225.0 FACILITY 
callTransferldentify.inv 



H.225.0 FACILITY 
callTransferldentify.res 



(After rerouteing 



H.225.0 RELEASE COMPLETE complete) 



Figure B.3: Example of scenario AC1 
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B.4 Scenario AC2 



PISN 



Interworking unit 



H.225.0 FACILITY 
callTransferldentify.inv 



H.225.0 FACILITY 
callTransferldentify.res 



H.225.0 RELEASE COMPLETE 



IP network 



QSIG FACILITY 
callTransferldentify.inv 



QSIG FACILITY 
callTransferldentify.res 

(After rerouteing 

QSIG DISCONNECT complete) 



QSIG RELEASE 



QSIG RELEASE COMPLETE 

Figure B.4: Example of scenario AC2 



B.5 Scenario BC1 or BC*1 



PISN 



Interworking unit 



QSIG FACILITY 

callTransferSetup.inv (BC1) 

or ssctSetup.inv (BC*1 ) 



QSIG CALL PROCEEDING 



QSIG ALERTING 

callTransferSetup.res (BC1) or 

ssctSetup.res (BC*1) 



IP network 



H.225.0 SETUP 
callTransferSetup. inv 



H.225.0 CALL PROCEEDING 



H.225.0 ALERTING 
callTransferSetup.res 



H.225.0 CONNECT 



QSIG CONNECT 
Figure B.5: Example of scenario BC1 or BC*1 
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B.6 Scenario BC2 or BC*2 



PISN 



Interworking unit 



H.225.0 FACILITY 
callTransferSetup. inv 



H.225.0 CALL PROCEEDING 



H.225.0 ALERTING 
callTransferSetup. res 



IP network 



QSIG SETUP 

callTransferSetup. inv (BC2) 

or ssctSetup.inv (BC*2) 



QSIG CALL PROCEEDING 



OSIG ALERTING 

callTransferSetup. res (BC2) or 

ssctSetup.res (BC*2) 



OSIG CONNECT 



H.225.0 CONNECT 

Figure B.6: Example of scenario BC2 or BC*2 



B.7 Scenario B1 , C1 , B*1 or C*1 



PISN 



Inten/vorking unit 



OSIG FACILITY 
callTransferComplete.inv 



OSIG FACILITY 
callTransferUpdate. inv 



OSIG FACILITY 
callTransferUpdate. inv 



OSIG FACILITY 

callTransferActive.inv 

(scenario B1 only) 



IP network 



H.225.0 FACILITY 
callTransferComplete.inv 



H.225.0 FACILITY 
callTransferUpdate. inv 



H.225.0 FACILITY 
callTransferUpdate. inv 



H.225.0 FACILITY 

callTransferActive.inv 

(scenario B1 only) 



Figure B.7: Example of scenario B1, C1, B*1 or C*1 



ETSI 



53 



ETSI TS 101 907 VI .2.1 (2001-08) 



B.8 Scenario B2, C2, B*2 or C*2 



PISN 



Interworking unit 



H.225.0 FACILITY 
callTransferComplete.inv 



H.225.0 FACILITY 
callTransferUpdate. inv 



H.225.0 FACILITY 
callTransferUpdate. inv 

H.225.0 FACILITY 

callTransferActive.inv 

(scenario B2 only) 



IP network 



QSIG FACILITY 
callTransferComplete.inv 



QSIG FACILITY 
callTransferUpdate. inv 



QSIG FACILITY 
callTransferUpdate. inv 



QSIG FACILITY 

callTransferActive.inv 

(scenario B2 only) 



Figure B.8: Example of scenario B2, C2, B*2 or C*2 
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